Re: Telnet attack on SGI
Joe Hentzel (jhentzel@BLUE.WEEG.UIOWA.EDU)
Wed, 1 Nov 1995 15:17:59 -0600
> I've been playing with the telnet attack on the SGI, trying to figure out a
> good way around it since SGI apparently doesn't have a patch ready yet. I
> have figured an easy way to show how the bug operates, but haven't figured an
> easy way to stop it.
>
> # telnet
> telnet> environ define _RLD_ROOT /tmp
> telnet> environ export _RLD_ROOT
> telnet> o localhost
> Trying 127.0.0.1...
> Connected to localhost.xxx.xxx.xxx
> Escape character is '^]'.
>
>
> IRIX System V.4 (xxx)
>
> 7480:login: rld: Fatal Error: cannot map soname 'libgen.so' using any of the
> filenames /tmp/usr/lib/libgen.so:/tmp/lib/libgen.so:/tmp/lib/cmplrs/cc/libgen
> .so:/tmp/usr/lib/cmplrs/cc/libgen.so:/tmp/usr/lib/libgen.so.1:/tmp/lib/libgen
> .so.1:/tmp/lib/cmplrs/cc/libgen.so.1:/tmp/usr/lib/cmplrs/cc/libgen.so.1: -- e
> ither the file does not exist or the file is not mappable (with reason indica
> ted in previous msg)
> Connection closed by foreign host.
> #
Have you thrown together any shared libraris with the relevant functions
replaced with calls to a shell or something similar? It would be nice to
see the source code to telnet and login and the libraries themselves before
doing this, but its certainly not necessary...
With Linux and FreeBSD being vulnerable, getting a hold of source code
should be easy, although linux and freebsd systems are unlikely to be
targets of very many attacks.
> _RLD_ROOT isn't the only variable that the runtime linker will understand, I
> just picked this one as a good example. If you do a 'tog opt' in telnet before
> you open the connection to localhost you can watch the option negotiation and
> see the _RLD_ROOT variable being passed.
>
> There are two ways I know of to protect against this attack until SGI has a
> patch ready. One would be to write a wrapper that removes "dangerous"
> environment variables. Obviously, figuring out which ones are dangerous is
> the trick! Certainly anything that starts LD_ or _RLD should be removed. But
> there may always be others you don't know about. You'd take your wrapper and
> call it /usr/lib/iaf/scheme and rename the real /usr/lib/iaf/scheme to
> something like /usr/lib/iaf/scheme.real and have your wrapper call it (see
> below) You'd have to compile it non_shared, so it doesn't get hijacked by
> the bad environment variables itself. The other way I found is guaranteed to
> work, but breaks login slightly. If you create a simple wrapper program as
> follows:
>
> main(argc, argv)
> int argc;
> char **argv;
> {
> setuid(1);
> execv("/usr/lib/iaf/scheme.real", argv);
> }
>
> And compile it with the -non_shared option, call it /usr/lib/iaf/scheme and
> rename the old /usr/lib/iaf/scheme to /usr/lib/iaf/scheme.real, then you
> effectively have telnetd calling your wrapper, which sets its uid to 1, then
> calls the real login. I've only tested this on Irix 5.3, and most of my
> experience is with HPs, so I don't know if this works for all releases. But
> I know that on my 5.3 machine, telnetd calls /usr/lib/iaf/scheme directly,
> instead of /bin/login (which is a link to /usr/lib/iaf/scheme) Since the real
> login is not started as root, you see some odd things. I've noticed two
> things in particular: you get an error because quota is being run as uid 1
> instead of root when you login, and rlogin no longer works with .rhosts. I
> assume that's because login will only accept some options when not run as
> root, for obvious reasons. There may be other problems with it as well. But
> since login is setuid, the uids don't match and the runtime linker won't honor
> any of the "dangerous" variables.
This would seem a somewhat odd solution to the problem, but I assume the
problems with quota and such can be resolved relatively easily.
> I'm curious exactly to see exactly how the various vendors that have this
> vulnerability choose to fix it in the long term. In the short term, patching
> telnetd seems to be the solution. But what if the dynamic linker gets a new
> variable in the future, and the people responsible for that don't let the
> people responsible for telnetd know? A better fix, IMHO, would be some sort
> of way to compile some executables without support for altering paths in this
> way. HP by default does not allow you to modify the searching rules used for
> finding shared libraries. But with a linker option, you can allow the
> environment variable SHLIB_PATH to modify the searching rules. Its a bit less
> flexible than, say, Sun or SGI, but there are no worries about this sort of
> attack ever being possible unless HP compiled system binaries with this
> option, which they would of course be crazy to do.
Thanks for the information, its amazing how many differences there are
between systems. Have you looked at DG/UX, SVR4, Pyramid, or other
similar systems to see if their telnets support the passing of
environment variables?
Joe